REMARKS 

Reconsideration of the present application is respectfully requested. Claims 1, 6, 
8-10, 12, and 16 have been amended. Claims 4, 7, and 13-15 have been canceled. 
Claims 22-26 have been newly added. No new matter has been added. Applicants 
hereby respectfully request a telephone interview with the Examiner to be held 
before the Examiner's issuance of an office action in response to this RCE. 

Claim Rejections - §1 03(a) 

Claims 1-3, 5-6, 8-14 and 16-21 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Publication 2002/0056126 of Srikantan et al. (hereinafter 
"Srikantan"). 

Applicants' invention generally relates to a technique of reducing bursts in 
streaming media data traffic, in order to reduce congestion of downstream routers, 
servers, etc., particularly when a large number of clients have requested the same 
media data stream at substantially the same time. Such congestion can result in 
degradation in the quality and smoothness of the data streams that are ultimately 
delivered to the clients. 

In particular embodiments of the present invention, congestion in downstream 
nodes is reduced by reducing streaming media burst traffic, and more specifically, by 
adding to each packet's specified delivery time a delay value that has been pseudo- 
randomlv selected for each client. This technique virtually ensures that even if a large 
number of clients (e.g., 10,000 or more) request the same data stream at the same 
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time , there will not be a large number of clients assigned the exact same delivery time 



for a given data packet. This technique, therefore, has the effect of spreading the 
delivery times of a given data packet for multiple clients substantially evenly throughout 
a given time window, thereby reducing burst traffic. With the above remarks in mind, 
attention is directed to independent claim 1 . 
Claim 1, as currently amended, recites: 

1 . A method for reducing magnitudes of output traffic bursts in a streaming 
media cache, comprising: 

receiving a request from a first client system for a stream of media data, 
the stream of media data including a first streaming media data packet; 

receiving a request from a second client system for the stream of media 

data; 

receiving the first streaming media data packet from an upstream server, 
the first streaming media data packet including a delivery time, at which the 
first streaming media data packet is scheduled to be delivered to each of 
the first and second client systems; 

pseudo-randomly selecting a first delay value and adding the first 
delay value to the delivery time of the first streaming media data packet to 
form a first modified delivery time for the first streaming media data packet; 

pseudo-randomly selecting a second delay value and adding the 
second delay value to the delivery time of the first streaming media data 
packet to form a second modified delivery time for the first streaming 
media data packet; 

modifying the first streaming media data packet with the first modified 
delivery time to form a first modified first streaming media data packet; 

modifying the first streaming media data packet with the second modified 
delivery time to form a second modified first streaming media data packet; 

outputting the first modified first streaming media data packet to the first 
client system at the first modified delivery time; and 

outputting the second modified first streaming media data packet to the 
second client system at the second modified delivery time. 
(Emphasis added). 

In contrast, Srikantan does not teach or suggest the above emphasized 
limitations, namely pseudo-randomly selecting a first delay value and adding the first 
delay value to the delivery time of the first streaming media data packet to form a first 
modified delivery time for the first streaming media data packet, and pseudo-randomly 
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selecting a second delay value and adding the second delay value to the delivery time 

of the first streaming media data packet to form a second modified delivery time for the 

first streaming media data packet (the first streaming media data packet is scheduled to 

be delivered to each of a first and second client systems at the delivery time) . 

The Examiner alleges that Srikantan's paragraph 26 teaches modifying a 

specified packet delivery time of a packet of data. Paragraph 26 states: 

Streaming real-time media places constraints upon the issuing server, 
because delivery of each frame or other unit of the media must be 
performed in a specified order and within a certain period of time. Thus, 
despite the number of clients it serves, a media streaming server must 
strive to meet the demands of streaming real-time media so that the 
quality of service to the users does not drop to an unacceptable level. For 
example, regardless of the type of program (i.e., live or pre-recorded) and 
mode of streaming (i.e., unicast or multicast), streamed media is 
generally compressed to decrease the bandwidth that it consumes in 
transit, thus helping to ensure timely delivery of media to a client. 

Thus, as can be seen, paragraph 26 firstly points out a problem associated with 
steaming real-time media, namely, delivery of each frame or other unit of media by an 
issuing server must be performed in a specified order and within a certain period of time 
despite the number of clients the issuing server servers. Then paragraph 26 discloses 
a technique of compressing the streamed media to decrease the bandwidth to ensure 
timely delivery of media to a client. Paragraph 26, however, contains no discussion or 
indication of modifying a specified packet delivery time of a packet of data . 

The Examiner acknowledges that Srikantan does not explicitly teach or suggest 
modifying the media data packet's delivery time for first and second client, respectively 
(Final Office Action mailed on 3/8/2007, page 3). The Examiner, however, alleges that 
Srikantan discloses media frames of a live or pre-recorded event from a single source 
being simultaneously streamed in a real-time to multiple users in a specified order within 
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a certain period of time. The Examiner further alleges that time delay techniques are 
utilized in order to deliver the packets of a single live or pre-recorded transmission to 
multiple clients as described by Srikantan. In order to support the above allegation, the 
Examiner cites Srikantan's paragraphs 25, 26, 55 and 56, and alleges that "different 
time indices" disclosed in Srikantan reads on the first and second delay values recited in 
claim 1 . The Examiner then concludes that it would have been obvious to one with 
ordinary skill in the art to understand that the method disclosed in Srikantan involves 
modifying the media data packet's delivery time belonging to single media source in 
order to accommodate simultaneous real-time transmission to multiple clients. 

As disclosed in Srikantan, a "time index" (or "time indices") is completely different 
from a delay value such as recited in claim 1 . A time index in Srikantan is used for 
determining where a segment is located in a track or media file (see paragraph 3 and 
claim 17 of Srikantan). In other words, time index identifies and locates a media 
segment's time position in a track or media program (see Abstract). Thus, metadata 
regarding time indices is used in Srikantan to make sure a media track or file is 
streamed in the correct sequence with appropriate timing (see paragraph 3). 

In addition, "delivery of each frame or other unit of the media must be performed 
in a specified order and within a certain period of time" (alleged by the Examiner and 
disclosed in Srikantan's paragraph 26) does not necessarily require time delay 
techniques to be used. 

In the Response to Arguments section of the final office action mailed on 
3/8/2007, the Examiner additionally argues that "Srikantan, on paragraphs 26, 55, 56 
and Figure 4, discloses serving streams of media which is either live or pre-recorded 
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from one track to multiple clients and further states that the same media is streamed to 
each client, but with different timing ." The Examiner interprets that serving streams of 
media to multiple clients but with different timing means streaming media from different 
time indices within a media track to different clients at any given time. Thus, the 
Examiner is essentially arguing that Srikantan teaches or suggests delaying the delivery 
of a packet to different client systems. As discussed above, time index is used to 
identify and locate a media segment in a track or media program. Therefore, streaming 
media from different time indices within a media track to different clients at any given 
time means streaming different media segments within a media track to different clients 
at any given time. Thus, according to the Examiner's above allegation and 
interpretation, paragraphs 26, 55, 56, and Figure 4 teach or suggest that a streaming 
server may, at any given time, stream different segments of the same media to different 
clients. As further explained in paragraphs 56-63 of Srikantan, the media streamed to 
different clients are pre-recorded media and the reason that different segments of the 
media are streamed to different clients at any given time is that different clients 
reguested the streaming of the same media at different time . Thus, paragraphs 26, 55, 
56, and Figure 4 contain no discussion or indication of any technique of delaying the 
delivery of a packet of data to different clients with differently calculated delay time, 
even the packet of data is scheduled to be delivered to each of the clients at the same 
delivery time. 

Thus, at least for the foregoing reasons, Srikantan does not teach or suggest all 
of the limitations of claim 1. Therefore, claim 1 and all claims which depend on it are 
patentable over Srikantan. 
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Independent claims 9, 16, and 22 each includes limitations similar to those 
discussed above for claim 1 . Therefore, claims 9, 16, 22 and all claims which depend 
on them are also patentable over Srikantan. 

Conclusion 

For the foregoing reasons, the present application is believed to be in condition 
for allowance, and such action is earnestly requested. 

If there are any additional charges, please charge Deposit Account No. 02-2666. 
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